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(1) REAL PARTY IN INTEREST 

The real party in interest in this matter is NCR Corporation, Dayton, Ohio, 
by virtue of an assignment recorded at reel 1 1339, frame 0581, on November 16, 
2000. 

(2) RELATED APPEALS AND INTERFERENCES 

Applicant is aware of no other active appeals or interferences related to this 
application. 

(3) STATUS OF CLAIMS 

Claims 1 through 30 are pending. All have been rejected and are under 
appeal. A listing of claims is attached as an appendix to this brief. 

(4) STATUS OF AMENDMENTS 

All amendments have been entered prior to appeal and are reflected in the 
listing of claims appended to this brief. 

(5) SUMMARY OF CLAIMED SUBJECT MATTER 

The invention involves a technique for use in managing data in a 
database system, in particular executing one or more locks on a set of 
target data when performing an operation on that data (page 4, lines 3-13). 
As defined in claims 1,7, 15 and 21, the technique involves receiving a 
request to perform an operation (e.g., a data-manipulation or data- 
definition operation) on a set of target data residing in the database system 
(Fig. 2, 200; page 8, lines 5-7) and then executing that operation in the 
database system where the target data resides (Fig. 2, 225; page 5, lines 20- 
22, and page 8, lines 19-20). At some point after execution of the 
operation has begun, a lock is placed on the target data to prevent 
concurrent execution of other operations on the target data (Fig. 2, 250; 
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page 5, lines 20-22). It is important to note that (1) the lock is not placed 
on the target data until after execution of the operation has begun, and (2) 
the operation is executed directly on the set of target data residing in the 
database system. 

As defined in claim 30, the technique involves receiving an 
instruction from a user to perform a data-definition operation (e.g., a 
CREATE TABLE, CREATE INDEX, or DROP USER operation) on a set 
of target data (Fig. 2, 200; page 8, lines 5-7) and, in response to that 
instruction, placing an initial lock (e.g., an ACCESS or READ lock) on the 
target data at a level that prevents at least one type of concurrent operation 
on the data (Fig. 2, 215 & 225; page 5, line 29, to page 6, line 5, and page 
8, lines 17-18). At some point after execution of the data-definition 
operation has begun, the lock is upgraded to a higher locking level (e.g., an 
EXCLUSIVE lock), one that excludes all types of concurrent operations on 
the target data (Fig. 2, 250; page 6, lines 2-5). 

As defined in claim 28, the technique involves receiving an 
instruction to perform a particular type of data-definition operation (Fig. 2, 
200; page 7, lines 1-16) - one that modifies the characteristics of the 
database itself or of a user of the database - and then initiating execution 
of that operation on the targeted data or user (Fig. 2, 220). At some point 
while the operation is executing, another operation is executed 
concurrently on objects within the same database or on the same user (page 
7, lines 12-16). The technique, as defined in this claim, thus allows 
execution of concurrent operations on a targeted database or user while the 
characteristics of that database or user are being modified. 

(6) GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

The issue before the Board is whether claims 1-30 are patentable under 35 
U.S.C. § 102(e) in view of U.S. Patent 6,070,170, to Friske. 
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(7) ARGUMENT 

A. Claims 1-27 

Friske does not show, nor does he suggest, executing an operation on a set 
of target data "in the database" where it resides and then, "at some point after 
execution has begun, placing a lock on the target data to prevent concurrent 
execution of other operations" on that data, as claimed. Friske states clearly that a 
"target data set" to be reorganized "is 'unloaded' from the logical database" by 
"copying [the] data set to flat files" and then placing "the unloaded target data . . . 
into a shadow location" in a storage unit. (Col. 6, lines 5-1 1 and 25-28.) Friske 
then carries out the reorganization operation on this shadow copy, applying to it 
"log records" that reflect "changes which occurred to the original data set after the 
target data set was unloaded." (Col. 6, lines 33-35.) Finally, after the target data 
set is updated at its shadow location, "the original data set is then replaced with the 
target data set." (Col. 6, lines 42-43.) 

This lengthy passage in Friske makes it clear that Friske does not execute 
an operation directly on a set of target data that resides in the database, but instead 
"unloads" the data from the database to a shadow location before operating on it. 
As a result, Friske does not meet the limitations of these claims, and the claims are 
allowable over this reference. 

B. Claims 28-29 

Despite the Office's assertion to the contrary on page 2 of the action dated 
November 28, 2003, Friske does not even hint at, let alone teach, the execution of 
a MODIFY DATABASE/USER operation, as claimed by Applicant. The 
MODIFY DATABASE/USER operation is a particular type of data-definition 
operation that allows modification of (1) the characteristics of a database user or 
(2) database options, such as the amount of permanent space ("PERM"), 
temporary space ("TEMP"), or spool space ("SPOOL") allocated to the database. 
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{See Applicant's disclosure, page 7.) When applied to the database, the MODIFY 
DATABASE/USER operation does not modify data residing within the database, 
but rather modifies the structure or characteristics of the database itself. 

Friske is simply oblivious to this type of data-definitition operation. As 
such, it follows that Friske cannot possibly show or suggest the concurrent 
execution of other operations "within the targeted database or user" while 
executing such a data-definition operation. These claims, therefore, are allowable 
over Friske. 

C Claim 30 

The Office has tried in its most recent action (pages 2-3) to equate Friske' s 
"non-blocking drain" with both the "initial lock" and the "final lock" of 
Applicant's claim. This comparison, however, simply does not hold. Applicant's 
"initial lock" is one "that prevents at least one type of concurrent operation on the 
target data," while the "final lock" is one "that excludes all types of concurrent 
operations on the target data." Friske' s "non-blocking drain" does neither. 

In Friske' s own words, "the non-blocking drain does not acquire a 

traditional lock on the target data set With the non-blocking drain, any 

requests to access the target data set will not be blocked This allows other 

processes that need to use the target data set to access the data set even when the 
reorganization process is taking place." (Col. 6, lines 58-67, emphasis added.) 

Both the "initial lock" and the "final lock" of Applicant's claim prevent "at 
least one type of concurrent operation on the target data." Friske' s "non-blocking 
drain," on the other hand, prevents no operations whatsoever. This "non-blocking 
drain," therefore, could serve as neither the "initial lock" nor the "final lock" of 
Applicant's claim, and thus the claim is patentable over the Friske reference. 
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D. Conclusion 

The Friske patent does not show or suggest the features of 
Applicant's invention as set forth in any of the claims. Applicant therefore 
asks the Board to reverse the rejection and allow all of the claims. 

Please apply any charges or credits that might be due, except the 
issue fee, to Deposit Account 14-0225. 



NCR Corporation 

1700 South Patterson Blvd. 

Dayton, Ohio 45479 

Tel. No. (858) 485-4903 
Fax No. (858) 485-2581 



Respectfully, 




Harden E. Stevens, in 
Reg. No. 55,649 
for 



John D. Cowart 
Reg. No. 38, 415 
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(8) LISTING OF CLAIMS APPENDIX 

Claim 1 : A method for use in managing data in a database system, comprising: 
receiving a request to perform an operation on a set of target data residing in the 
database; 

executing the operation in the database on the set of target data; and 
at some point after execution has begun, placing a lock on the target data to 
prevent concurrent execution of other operations on the target data. 

Claim 2: The method of claim 1, comprising placing an initial lock on the target 
data at a level that prevents concurrent execution of at least one operation and, at some 
point after execution has begun, placing a final lock on the target data at a level that 
prevents concurrent execution of a larger set of operations. 

Claim 3: The method of claim 2, where the initial lock allows concurrent 
execution of operations that involve reading the target data. 

Claim 4: The method of claim 2, where the final lock prevents concurrent 
execution of all operations on the target data. 

Claim 5: The method of claim 2, further comprising allowing a user to specify 
the type of lock initially placed on the data. 

Claim 6: The method of claim 1 , where the operation is one of the following 
types: a COLLECT STATISTICS operation, a CREATE INDEX operation, and an 
ALTER TABLE operation. 
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Claim 7: A database system comprising: 
at least one storage device; 

at least one computing node configured to deliver data to and retrieve data from 
the storage device; and 

a database-management component configured to: 

receive a request to perform an operation on a set of target data residing in 
the database; 

execute the operation in the database on the set of target data; and 
at some point after execution as begun, place a lock on the target data to 
prevent concurrent execution of other operations on the target data. 

Claim 8: The system of claim 7, where the database-management system is 
configured to place an initial lock on the target data at a level that prevents concurrent 
execution of at least one operation and, at some point after execution has begun, placing a 
final lock on the target data at a level that prevents concurrent execution of a larger set of 
operations. 

Claim 9: The system of claim 8, where the initial lock allows concurrent 
execution of at least one other operation on the target data. 

Claim 10: The system of claim 8, where the subsequent lock prevents concurrent 
execution of all other operations on the target data. 

Claim 1 1 : The system of claim 8, where the database-management system is 
configured to allow a user to specify the type of lock initially placed on the data. 

Claim 12: The system of claim 7, comprising multiple computing nodes and 
multiple storage devices, where each storage node is configured to manage storage of 
data on at least a subset of the storage devices. 
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Claim 13: The system of claim 12, where the database-management system is 
configured to place the lock on a block of data that is spread across more than one of the 
storage devices. 

Claim 14: The system of claim 7, where the operation is one of the following 
types: a COLLECT STATISTICS operation, a CREATE INDEX operation, and an 
ALTER TABLE operation. 

Claim 1 5: A computer program, stored on at least one computer-readable storage 
medium, for use in managing data in a database system, comprising executable 
instructions that, when executed by a computer, cause the computer to: 

receive a request to perform an operation on a set of target data residing in the 
database; 

execute the operation in the database on the set of target data; and 
at some point after execution has begun, place a lock on the target data to prevent 
concurrent execution of other operations on the target data, 

Claim 16: The program of claim 1 5, where the program causes the computer to 
place an initial lock on the target data at a level that prevents concurrent execution of at 
least one operation and, at some point after execution has begun, placing a final lock on 
the target data at a level that prevents concurrent execution of a larger set of operations. 

Claim 17: The program of claim 16, where the initial lock allows concurrent 
execution of at least one other operation on the target data. 

Claim 18: The program of claim 16, where the subsequent lock prevents 
concurrent execution of all other operations on the target data. 

Claim 19: The program of claim 16, where the program causes the computer to 
allow a user to specify the type of lock initially placed on the data. 
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Claim 20: The program of claim 15, where the operation is one of the following 
types: a COLLECT STATISTICS operation, a CREATE INDEX operation, and an 
ALTER TABLE operation. 

Claim 21: A method for use in managing data in a database system, comprising: 
receiving an instruction from a user to perform a data-definition operation on a set 

of target data residing in the database; 

placing an initial lock on the target data at a level that allows at least one 

concurrent operation on the target data; 

executing the operation in the database on the set of target data; and 

at some point after execution has begun, placing a final lock on the target data at a 

level that excludes all other concurrent operations on the target data. 

Claim 22: The method of claim 21, where the initial lock excludes at least some 
concurrent operations on the target data. 

Claim 23 : The method of claim 2 1 , further comprising allowing a user to select 
the level of the initial lock. 

Claim 24: The method of claim 21, where placing an initial lock on the target 
data includes placing one of the following types of locks on the target data: an ACCESS 
lock; a READ lock; and a WRITE lock. 

Claim 25: The method of claim 21 , where placing a final lock on the target data 
includes placing an EXCLUSIVE lock on the target data. 

Claim 26: The method of claim 21, where placing an initial lock on the target 
data includes locking an entire table. 
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Claim 27: The method of claim 21, where receiving the instruction from the user 
includes receiving an instruction to perform one of the following operations: a CREATE 
INDEX operation, a COLLECT STASTICS operation, and an ALTER TABLE 
operation. 

Claim 28: A method for use in managing data in a database system, the method 
comprising: 

receiving an instruction to perform a MODIFY DATABASE/USER operation on 
a set of target data; 

initiating execution of the operation; and 

at some point during execution of the operation, concurrently executing another 
operation on objects within the targeted database or user. 

Claim 29: The method of claim 28, further comprising maintaining an ACCESS 
lock on the target database or user and no locks on the immediate parent of the targeted 
database or user during execution of the MODIFY DATABASE/USER operation. 

Claim 30: A method for use in managing data in a database system, comprising: 
receiving an instruction from a user to perform a data-definition operation on a set 
of target data; 

placing an initial lock on the target data at a level that prevents at least one type of 
concurrent operation on the target data; 

initiating execution of the operation on the target data; and 

at some point after execution has begun, placing a final lock on the target data at a 
level that excludes all types of concurrent operations on the target data. 
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(9) EVIDENCE APPENDIX 

None. 



(10) RELATED PROCEEDINGS APPENDIX 

None. 
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